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1. Introduction 


This document specifies the conventions for using the Hierarchical Signature System (HSS) / 
Leighton-Micali Signature (LMS) hash-based signature algorithm with the CBOR Object Signing 
and Encryption (COSE) [RFC8152] syntax. The LMS system provides a one-time digital signature 
that is a variant of Merkle Tree Signatures (MTS). The HSS is built on top of the LMS system to 
efficiently scale for a larger number of signatures. The HSS/LMS algorithm is one form of a hash- 
based digital signature, and it is described in [HASHSIG]. The HSS/LMS signature algorithm can 
only be used for a fixed number of signing operations. The number of signing operations 
depends upon the size of the tree. The HSS/LMS signature algorithm uses small public keys, and 
it has low computational cost; however, the signatures are quite large. The HSS/LMS private key 
can be very small when the signer is willing to perform additional computation at signing time; 
alternatively, the private key can consume additional memory and provide a faster signing time. 
The HSS/LMS signatures [HASHSIG] are currently defined to use exclusively SHA-256 [SHS]. 


1.1. Motivation 


Recent advances in cryptanalysis [BH2013] and progress in the development of quantum 
computers [NAS2019] pose a threat to widely deployed digital signature algorithms. As a result, 
there is a need to prepare for a day that cryptosystems, such as RSA and DSA, that depend on 
discrete logarithm and factoring cannot be depended upon. 


If large-scale quantum computers are ever built, these computers will have more than a trivial 
number of quantum bits (qubits), and they will be able to break many of the public-key 
cryptosystems currently in use. A post-quantum cryptosystem [PQC] is a system that is secure 
against such large-scale quantum computers. When it will be feasible to build such computers is 
open to conjecture; however, RSA [RFC8017], DSA [DSS], Elliptic Curve Digital Signature 
Algorithm (ECDSA) [DSS], and Edwards-curve Digital Signature Algorithm (EdDSA) [RFC8032] are 
all vulnerable if large-scale quantum computers come to pass. 


Since the HSS/LMS signature algorithm does not depend on the difficulty of discrete logarithm or 
factoring, the HSS/LMS signature algorithm is considered to be post-quantum secure. The use of 
HSS/LMS hash-based signatures to protect software update distribution will allow the 
deployment of future software that implements new cryptosystems. By deploying HSS/LMS today, 
authentication and integrity protection of the future software can be provided, even if advances 
break current digital-signature mechanisms. 


1.2. Terminology 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD 
NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to 
be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in 
all capitals, as shown here. 
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2. LMS Digital Signature Algorithm Overview 


This specification makes use of the hash-based signature algorithm specified in [HASHSIG], 
which is the Leighton and Micali adaptation [LM] of the original Lamport-Diffie-Winternitz- 
Merkle one-time signature system [M1979][M1987][M1989a][M1989b]. 


The hash-based signature algorithm has three major components: 


e Hierarchical Signature System (HSS) -- see Section 2.1 
e Leighton-Micali Signature (LMS) -- see Section 2.2 
e Leighton-Micali One-time Signature (LM-OTS) Algorithm-- see Section 2.3 


As implied by the name, the hash-based signature algorithm depends on a collision-resistant 
hash function. The hash-based signature algorithm specified in [HASHSIG] currently makes use 
of the SHA-256 one-way hash function [SHS], but it also establishes an IANA registry to permit 
the registration of additional one-way hash functions in the future. 


2.1. Hierarchical Signature System (HSS) 


The hash-based signature algorithm specified in [HASHSIG] uses a hierarchy of trees. The N-time 
Hierarchical Signature System (HSS) allows subordinate trees to be generated when needed by 
the signer. Otherwise, generation of the entire tree might take weeks or longer. 


An HSS signature, as specified in [HASHSIG], carries the number of signed public keys (Nspk), 
followed by that number of signed public keys, followed by the LMS signature, as described in 
Section 2.2. The public key for the topmost LMS tree is the public key of the HSS system. The LMS 
private key in the parent tree signs the LMS public key in the child tree, and the LMS private key 
in the bottom-most tree signs the actual message. The signature over the public key and the 
signature over the actual message are LMS signatures, as described in Section 2.2. 


The elements of the HSS signature value for a stand-alone tree (a top tree with no children) can 
be summarized as: 


u32str (0) || 
lms_signature /*x signature of message */ 


where the notation comes from [HASHSIG]. 


The elements of the HSS signature value for a tree with Nspk signed public keys can be 
summarized as: 
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u32str(Nspk) | | 
signed_public_key[0] || 
signed_public_key[1] || 


signed_public_key[Nspk-2] | | 
signed_public_key[Nspk-1] || 
lms_signature /* signature of message x/ 


As defined in Section 3.3 of [HASHSIG], a signed_public_key is the Ims_signature over the public 
key followed by the public key itself. Note that Nspk is the number of levels in the hierarchy of 
trees minus 1. 


2.2. Leighton-Micali Signature (LMS) 


Subordinate LMS trees are placed in the HSS structure, as discussed in Section 2.1. Each tree in 
the hash-based signature algorithm specified in [HASHSIG] uses the Leighton-Micali Signature 
(LMS) system. LMS systems have two parameters. The first parameter is the height of the tree, h, 
which is the number of levels in the tree minus one. The [HASHSIG] includes support for five 
values of this parameter: h=5, h=10, h=15, h=20, and h=25. Note that there are 2^h leaves in the 
tree. The second parameter is the number of bytes output by the hash function, m, which is the 
amount of data associated with each node in the tree. The [HASHSIG] specification supports only 
SHA-256 with m=32. An IANA registry is defined so that other hash functions could be used in the 
future. 


The [HASHSIG] specification supports five tree sizes: 


e LMS_SHA256_M32_H5 

e LMS_SHA256_M32_H10 
e LMS_SHA256_M32_H15 
e LMS_SHA256_M32_H20 
e LMS_SHA256_M32_H25 


The [HASHSIG] specification establishes an IANA registry to permit the registration of additional 
hash functions and additional tree sizes in the future. 


The [HASHSIG] specification defines the value I as the private key identifier, and the same I value 
is used for all computations with the same LMS tree. The value I is also available in the public 
key. In addition, the [HASHSIG] specification defines the value T[r] as the m-byte string 
associated with the ith node in the LMS tree, and the nodes are indexed from 1 to 24(h+1)-1. 
Thus, T[1] is the m-byte string associated with the root of the LMS tree. 


The LMS public key can be summarized as: 


u32str(lms_algorithm_type) || u32str(otstype) || I || T[1] 
As specified in [HASHSIG], the LMS signature consists of four elements: 


e the number of the leaf associated with the LM-OTS signature, 
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e an LM-OTS signature, as described in Section 2.3, 
e a type code indicating the particular LMS algorithm, and 


e an array of values that is associated with the path through the tree from the leaf associated 
with the LM-OTS signature to the root. 


The array of values contains the siblings of the nodes on the path from the leaf to the root but 
does not contain the nodes on the path itself. The array for a tree with height h will have h 
values. The first value is the sibling of the leaf, the next value is the sibling of the parent of the 
leaf, and so on up the path to the root. 


The four elements of the LMS signature value can be summarized as: 


u32str(q) || 

ots_signature || 

u32str(type) | | 

path[0] || path[1] || ... || path[h-1] 


2.3. Leighton-Micali One-Time Signature (LM-OTS) Algorithm 


The hash-based signature algorithm depends on a one-time signature method. This specification 
makes use of the Leighton-Micali One-time Signature (LM-OTS) Algorithm [HASHSIG]. An LM-OTS 
has five parameters: 


n: The number of bytes output by the hash function. For SHA-256 [SHS], n=32. 


H: A preimage-resistant hash function that accepts byte strings of any length and returns an 
n-byte string. 


w: The width in bits of the Winternitz coefficients. [HASHSIG] supports four values for this 
parameter: w=1, w=2, w=4, and w=8. 


p: The number of n-byte string elements that make up the LM-OTS signature. 


ls: The number of left-shift bits used in the checksum function, which is defined in Section 4.4 
of [HASHSIG]. 


The values of p and ls are dependent on the choices of the parameters n and w, as described in 
Appendix B of [HASHSIG]. 


The [HASHSIG] specification supports four LM-OTS variants: 


e LMOTS_SHA256_N32_W1 
e LMOTS_SHA256_N32_W2 
e LMOTS_SHA256_N32_W4 
e LMOTS_SHA256_N32_W8 


The [HASHSIG] specification establishes an IANA registry to permit the registration of additional 
hash functions and additional parameter sets in the future. 
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Signing involves the generation of C, which is an n-byte random value. 


The LM-OTS signature value can be summarized as the identifier of the LM-OTS variant, the 
random value, and a sequence of hash values (y[0] through y[p-1]), as described in Section 4.5 of 
[HASHSIG]: 


u32str(otstype) || C || yio] || ... |] yip l] 


3. Hash-Based Signature Algorithm Identifiers 


The CBOR Object Signing and Encryption (COSE) [RFC8152] supports two signature algorithm 
schemes. This specification makes use of the signature with appendix scheme for hash-based 
signatures. 


The signature value is a large byte string, as described in Section 2. The byte string is designed 
for easy parsing. The HSS, LMS, and LM-OTS components of the signature value format include 
counters and type codes that indirectly provide all of the information that is needed to parse the 
byte string during signature validation. 


When using a COSE key for this algorithm, the following checks are made: 


e The 'kty' field MUST be 'HSS-LMS'. 
e If the ‘alg’ field is present, it MUST be 'HSS-LMS'. 
e If the 'key_ops' field is present, it MUST include 'sign' when creating a hash-based signature. 


e If the 'key_ops' field is present, it MUST include 'verify' when verifying a hash-based 
signature. 


e If the 'kid' field is present, it MAY be used to identify the top of the HSS tree. In [HASHSIG], 
this identifier is called T', and it is the 16-byte identifier of the LMS public key for the tree. 


4. Security Considerations 


The security considerations from [RFC8152] and [HASHSIG] are relevant to implementations of 
this specification. 


There are a number of security considerations that need to be taken into account by 
implementers of this specification. 


Implementations MUST protect the private keys. Compromise of the private keys may result in 
the ability to forge signatures. Along with the private key, the implementation MUST keep track of 
which leaf nodes in the tree have been used. Loss of integrity of this tracking data can cause a 
one-time key to be used more than once. As a result, when a private key and the tracking data 
are stored on nonvolatile media or in a virtual machine environment, failed writes, virtual 
machine snapshotting or cloning, and other operational concerns must be considered to ensure 
confidentiality and integrity. 
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When generating an LMS key pair, an implementation MUST generate each key pair 
independently of all other key pairs in the HSS tree. 


An implementation MUST ensure that an LM-OTS private key is used to generate a signature only 
one time and ensure that it cannot be used for any other purpose. 


The generation of private keys relies on random numbers. The use of inadequate pseudorandom 
number generators (PRNGs) to generate these values can result in little or no security. An 
attacker may find it much easier to reproduce the PRNG environment that produced the keys, 
searching the resulting small set of possibilities rather than brute-force searching the whole key 
space. The generation of quality random numbers is difficult, and [RFC4086] offers important 
guidance in this area. 


The generation of hash-based signatures also depends on random numbers. While the 
consequences of an inadequate PRNG to generate these values is much less severe than in the 
generation of private keys, the guidance in [RFC4086] remains important. 


5. Operational Considerations 


The public key for the hash-based signature is the key at the root of Hierarchical Signature 
System (HSS). In the absence of a public key infrastructure [RFC5280], this public key is a trust 
anchor, and the number of signatures that can be generated is bounded by the size of the overall 
HSS set of trees. When all of the LM-OTS signatures have been used to produce a signature, then 
the establishment of a new trust anchor is required. 


To ensure that none of the tree nodes are used to generate more than one signature, the signer 
maintains state across different invocations of the signing algorithm. Section 9.2 of [HASHSIG] 
offers some practical implementation approaches around this statefulness. In some of these 
approaches, nodes are sacrificed to ensure that none are used more than once. As a result, the 
total number of signatures that can be generated might be less than the overall HSS set of trees. 


A COSE Key Type Parameter for encoding the HSS/LMS private key and the state about which 
tree nodes have been used is deliberately not defined. It was not defined to avoid creating the 
ability to save the private key and state, generate one or more signatures, and then restore the 
private key and state. Such a restoration operation provides disastrous opportunities for tree 
node reuse. 


6. IANA Considerations 


IANA has added entries for the HSS/LMS hash-based signature algorithm in the "COSE 
Algorithms" registry and added HSS/LMS hash-based signature public keys in the "COSE Key 
Types" registry and the "COSE Key Type Parameters" registry. 


6.1. COSE Algorithms Registry Entry 
The new entry in the "COSE Algorithms" registry [IANA] appears as follows: 
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Name: HSS-LMS 

Value: -46 

Description: HSS/LMS hash-based digital signature 
Reference: RFC 8778 

Recommended: Yes 


6.2. COSE Key Types Registry Entry 
The new entry in the "COSE Key Types" registry [IANA] appears as follows: 


Name: HSS-LMS 

Value: 5 

Description: Public key for HSS/LMS hash-based digital signature 
Reference: RFC 8778 


6.3. COSE Key Type Parameters Registry Entry 
The new entry in the "COSE Key Type Parameters" registry [IANA] appears as follows: 


Key Type: 5 

Name: pub 

Label: -1 

CBOR Type: bstr 

Description: Public key for HSS/LMS hash-based digital signature 
Reference: RFC 8778 
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Appendix A. Examples 


This appendix provides a non-normative example of a COSE full message signature and an 
example of a COSE_Signi message. This section is formatted according to the extended CBOR 
diagnostic format defined by [RFC8610]. 


The programs that were used to generate the examples can be found at <https://github.com/cose- 
weg/Examples>. 


A.1. Example COSE Full Message Signature 


This section provides an example of a COSE full message signature. 


The size of binary file is 2560 bytes. 


98( 
[ 
/ protected / h'al0300' / 4{ 
\ content type \ 3:0 
anaes 
/ unprotected / {}, 
/ payload / 'This is the content.', 
/ signatures / [ 
[ 
/ protected / h'a101382d' / { 
Walen ais=46°\ HSSSEMS: \ 
Ey gs 
/ unprotected / { 
/ kid / 4:'ItsBig' 
is 
/ signature / h'00000000000000010000000391291de76ce6e24d1le2a 
9b60266519bc8ce889Ff814deb0fc00edd3129de3ab9bé6bfa3bf47d007d844af 7db74 
9ea97215e82 f456cbdd473812c6a042ae39539898752c89b60a276ec8a9 feab900e2 
5bd feQab8e7 73aalc36ae214d67c65bb68630450a5db2c7c6403b77 f6éa9bf4d30a02 
19db5cced884d7514f3cbd19220020bf3045b0e5c6955b32864F16F97da02 fOcbfea 
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70458b07032e30b0342d75b8 f3dc6871442e6384b10 £559 F5dc594a214924c48ccc3 
37078665653 fc740340428138b0 fb5154f2f2cb291ladO05ace7acae60031b2d09b2F4 
17712d1c01e34b165af2e070f5a521a85a5 fb3dd2a6288947bcbd5e2265d3670bd61 
92eb2bf643964e2783d84aec343 f8e3571e4fcf09cbeea94e80470aa7252d1c733a5 
535907e66c7b9 FOb88b159dc2a7370ee47 F13e7e134d3d05e5f53 fac640b784a9b0 Ff 
183fe14217325626f487cc8d8cb9eaf0abb174ee0b7076c F39c45037cefdf3fle61b 
5174581214c09870b72c39737ec4c46a96199b66cad2990bcbe5bblabfde99107c7Ff 
7289395bf2a433598ede0b1969F23db949afb5b4d33831dae6c641a6355f8f9bF16Cc 
dffc4bf86891b93a557c2152ac8alde51c995344cc10cc4bc9ec fbb4e418bed0 F334 
af165339e6725dc4fcl1e995521e1be8a566d59b57cd130903b42d07087d63646ef8Ff 
c1e9e9071bb67a123 fdec3f37638cdaf0 f4bf3084074069171c17885b9431ad908d3 
6a6 f8a826256d2aa34f8aa0731a357c060db8e80 fefd61b1c323890e640633b98d17 
5d4d6ebf f800a71c fc864ec02837de9d0e079 FO F400acafd56805cb273e631ba395d 
23e86acf6eae6318la5afelf0a361lcbbd5fefeb7db0c95591ec3128e80dfbea9cadf 
89fc035d761c05d41e7a010892c42e8e2af62aa604F4e214cObb08075481F9cCc307a 
555adf333b9424f209b89f161032e413b047ae5ab0aal5643bb4c643446d2c9829eb 
256e7375ce9639047a24a44 F4da446b7359556f3ab3484c56511c68al140dc0531f65 
3105800d9f20990d4ebdc5ceea918d7ae95cOd7ec69a00d6a936b25 Fc1l9b9dFc5561 
400 f046191136c367038d6a9d0e0ae30dcdc4733712cbd5a2aee35315ef f5cla7e08 
5b68c5cf0c64c495df2ca6f030db04480a2e11d4a0a0dbf29d9463d5b9e41e346e49 
€894d5e43993c834c4746309c886d6131f2f92155cal1160bac9660802a947b5aba94 
b35357d13fdf02d2aeabe f568912 f68ae5d3a60214F6d00c4dd9 fFOafO9ebObf96I1cd 
9f27251d46899c28d87080ba2ead3e8193f51a789706ec32aacee9f4b14eeca91a25 
2fe894b30dc3938abbbe7d217948cae79ce3adb4d7d7df6756F3099F2543ed3b522b 
acab257503c9e07 fcd32cc32 fa9aal7977ecO5bc5 fe0 f5954d51F160f52d33f93166 
af68aa90261b3 f5ad273adacf2d0cb5b0c5402bfa62da67a52dcddfa463e72d2c005 
flac0ea3cb62364ee3419333612e07bf685006137a592e2 fcd58398265c4f f9el11e7 
0c2b79152e4604b4 f94676e955bcf F4dfc429a8a88728b95bfc2826e25ba6eab9cfb 
066c9911693ef ff242F7b51c3cb88546143b8ab2142dd3c9bda55d16 fe3084a86b74 
3f294dd9d0aa84f3ce3b083a5879a4762a756e9b41 Ff 4bdf8b71418073b0a0d4a9c13 
1882455ece23e50324c5 feea217920b0 f3109dcbdc81762e41b7ca27lefac8e39cc2 
6ebe085abdbf6b314a38929799fb7 feebee2e20b97056ed17ef3881e6e89330314dd 
7e9c629c46d fdb925c7c5 f5d243 f£159d964691745cd46579 fd0696479e1c49cbd2af 
879a2bce8576619cca7b6e516e6c94c1087441a81F11b9a83535b24ddc725a81a9d1 
ff62da2804c8d84c6e382065574282eal f23eaf648c fa9767afb098 fd81654d76133 
f5F39bcc762c9bc31Ff7 F4665ccOefa929b5c05dedd76143c63dc7018ab130c108ea9 
01be32b9d911b66dal13a1528c32a9694c899a772f8elfeO0c1l7eceb343e737d72cba 
06c f5ddac9a4d3df7ef391cf6595a6d8c14b0d80 f93023b1b3d4371239da98b67alb 
6a379422616282a16e8d1f97al30baf21e572bcca9labb760eac6957 f9b1b05e49e2 
d181874ac6dd160d1c717b73bd28ef55f08d47466d5aef754814c7e206fa9e2ec533 
85d14d52f7769d95ea50524f fb20dc7275b04d71d1967e3bbc6ed481f1fc5al5e78a 
1fd967d96045625645dbd173cccdd97661e995ce47d6b3ead96ee6d006a5ce6f4c97 
77fe2e3 f91bebe87 7cac8c6486dfce0315dc71bbb93879759b8981c5ff2elldebs809 
abf4280ee93d1711e73645b410acb518538ce3d4bdale355c988f068165668e99d6a 
8de356b4b13298036ad05d526c4a5e2591612a477b7e86550addel28cd71ee651d44 
99699000a02979e42bbcc f32c83bleb0 f f99aa4d352e20e0b3382422df2c2ed4ce90 
c94cf1a359e92ef971dc6db06047a333c2ebe827eb6d5Ff2811FfdbeObfOf1l2bf2094e 
Odcd8e418Ff3f691a60cebOce fb6 F45f47883d6b9 F320950e91266740c6dbfad6b3cf 
e56de0aa6658b0dc893bb6e49e6294537a7878e86cfc8e6c150675db1a89d188ea6e 
fe7d88ff57b39b8610e392811ee097ca61c4841e0 fbd346ed3ff6a5e412acb0d9f13 
022df2e7 fdaa8e0 face7366c8 ffe6f446995b564 Fc3d59c70 fecdb60a25e28650417 
157f43f3e72c3afc601509641cfd099a78130e1f7ba8333502ad4 f036f46411a43d0 
35e2ca0ed0c346d9aac5df05196c95c38e6e52763ed896b6d02464a910dda6cca340 
24e3b9c3723d26e2886ad724dd56ea285e8e4b60beec924d55dd700c38877b74552Ff 
ealf8741579b02061416131db390f628522885236b51f7aef23167d3a5fe5eadcd88 
b0e99b2b6bc56b0dea4 fb22146294766c28e5e7c834dbdcb6bfdd7bd8455252522F f 
2e974f6fd3fdal76749b7cdced5b9aba092b2982c89cb7d2b36348928c8Ff01170618 
ecf f14d9e0eed9d88d97e38bc f7a837 £674be5243 fc624c8afd3d105Ff462bfa939b8 


Housley Standards Track Page 12 


RFC 8778 HSS/LMS HashSig with COSE April 2020 


143a3a98f78fbb8c915e00bdbbf707b12c45784f4d1cb1426b583a0d5fbecif5eaé6d 
0067c090168cb788e532aca7 70c7Tbe366ec07e7808F1892b00000006ed1ce8c6e437 
918d43fba7bd9385694c41182703f6b7 f704deedd9384ba6 f8bc362c948646b3c984 
8803e6d9bal f7d3967f709cddd35dc77d60356f0c36808900b491cb4ecbbabec128e 
7c081a46e62a67b57640a0a78belcbhf7dd9d419a10cd8686d16621a80816bfdb5bdc5 
6211d72ca70b81f1117d129529a7570cf79cf52a7028a48538ecdd3b38d3d5d62d26 
246595c4fb73a525a5ed2c30524ebb1d8cc82e0c19bc4977c6898F F95 fd3d310b0ba 
e71696cef93c6a552456bf96e9d075e383bb7543c675842ba fb fc7cdb88483b3276c 
29d4f0a341c2d406e40d4653b7e4d04585lacf6a0a0ea9c71Ob805cced4635ee8c10 
7362 f0fc8d80c14d0ac49c516703d26d14752f34c1c0d2c4247581c18c2c f4de48e9 
ce949be7c888e9caebe4a415e291Fd107d21dc1f084b1158208249f28 f4Ff7c7e931b 
a7b3bd0d824a4570' 
] 
] 
] 
) 


A.2. Example COSE_Signi Message 


This section provides an example of a COSE_Sign1 message. 


The size of binary file is 2552 bytes. 


18( 
[ 
/ protected / h'al01382d' / { 
Naiona E 46 ea HSSSEMSH \ 
ef 
/ unprotected / { 
/ kid / 4:'ItsBig' 

Jo 

/ payload / 'This is the content.', 

/ signature / h'00000000000000000000000391291de76ce6e24d1e2a9b60 
266519bc8ce889f814deb0fc00edd3129de3ab9b9aa5b5ac783bdfOfe689f57 Fb204 
#1992dbc1ce2484f316c74bce3f2094c fa8e96a4a9548cead0f78ee5d549510d1910 
£647320448ae27ecce77249802a0c39c645bf8db08573af52c93d91fd0e217F245c7 
52c176b81514eb6e3067e0fbb329225eaa88c7d21635e32ae84213F89018cb06Ff1b8 
4e61eac348b690d7c6265c19 f9d868952d99826aecd417b5279dd674cd951c306016 
cfee4fee3bfcf5ee5a5ad08b5b4 f53bc93995Ff26c fe7c0c1c5ba2574c1f2d8470993 
e8bd47ef9b9c f309ef895226e92be6068345900961lidefbb9a43217956a0ab2959bb 
da0feca39de37e7c4a6cd8a5314d6b02b37 7406d5a5e589e91feaad f2e4ec1682bal 
£633cC7784499323e40da651f71d3c19e38c634d898b0c508324c0bfcf7c5f0a8c014 
b4af200a739f96cddba94daf86ce80c76158d4f5cf3cd2ba9Ff1393df47e556887Ff91 
68540485242a05ec6bcc76659ec3d0d2 fedae3 fd1608a701c226f5fd83c9b1led3152 
ddac7426c30e3390bec8f1da6174abe8d3568c9b76b149eb077d6laci5b8fb1ib8ce 
5f9d14e448e216f375e1f96a52d39619459b131026143e8809bad408 f5ef66cd3da2 
27431e68670c0b4b2c3801e1e9025blebed218e0956967158ccc274c704adcd8cc23 
€149a89eda25478742dadc15f233844535e4021000b5d557313d4f271875680e6d5e 
7f6681fdd19f8b9a748cabb2377aac1387 fdb80e618eb7d69a368729ca9aO92af9l1le 
be1c584c35fe62734d1d53d10b35dd02093a201c889ad37a558b610f1lab00179al11f 
881600e944cedc47a7ae6d828009d7c61ffea9dd5aa5406408e2e85dc056e47b5758 
9eabal8e792f4631af62d4588a1818167274273c69e7a0735be5dada7e224e3b178b 
3b093212eb74e762 £564a26d577aa22ebd8c7b4a999419908e2 f2d9c8689dc923905 
c198b9ee335d1le0de6d689655 fF446df fea99 7b6e58F5F648415233ede3b9d8a2db29 
e8c3dde5d8dbd55e6348cd9f421783db090e087de46425d62d513597b00d7de32 fad 
87752a79cee8b2a38b1e0 f2562836721cbb fba20F131130c009a436b93a0bb44fcbb 
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86228b1bf1a35f4fc626817924eaebd5b78d64a7970d18dade90c f0ad759b1c45d95 
3c08cd1189685077c5a56069da0944669d797496 fF 8F886 fea6f792598db2ac66b657 
af838ed3c3a914df fbb164170a1f63250b125eda53ecaeaf6ee0d2b8a3c804104d7e 
d575b66469bc59f37eec6c6f6 fb19e0 Ff 7ea02d7c85306230063adb58950589f 6Ff faf 
£1407233828ae0d fbe5889e5de00bb640a4bc24c3 F704488 fa669676a9ebbbed399b 
8a9ac0ee4cc944Ff864b21f642e04F610319ac9271f8bd820e77e41dac6553d234d94 
80e26142c0fa37416651d6450e1 f2082bd0213d6783elae3cc5c5af677C3316e173b 
a4716d6bc8a9d89383f8b025a0859b99a43daeaf8ddaed46d223b9b503651a67560b 
feb2f35ba544722620ec4086dcc7 7e6e87bb53F1F18c38368662be460ede31325cae 
aebf018a6 fa9d32e3c3a6898e15 fell4dcce51241c6lafabc36de3608b4d342712a8 
33615c6131e89e1d46b713d9638a08b5a768d53af0298b9c874ded7084358223840c 
2e78cd6fbfca695279a4c1883bb7de81b04a069de8277 F7 £5109C16938347a643713 
c9ac36fffc8bf141e899F48bc25c7b636d43bebc fa7742d4e1462263e56732ad2021 
eef8ce84023c4959c fd250343d62074724907de9d49ea2F6c968 Fd9e9bf28feafcdc 
81702108805dec60f2781272d2425a6ee29C66122d2c557867c1a5aed82131e06fc3 
84ec f49017elc9d6c f63b9F2285cc F890cbb9bbf796e0 Fd02101948b7ef663849367 
7b33fd787d9d3fc2c7cc7babc2laf8c748afb80c F86b45dc89FO0b9C7959621e85b98 
b542dc263db9255273bb9054a7 194748 f28373ba123d73fc71fef43e7e2ac9a8000 
8e85cf2f04aa433075dfc54c4de24a341lebf7cfle6b383dbba85898 fdc368017fd67 
c153e7a99la3a3cee6dae4fbe2fe6f25a8df314140a8176c8e6 fd0c6 f042ca66eb6a 
bba9a2502bb6d fa52960ae86a942a673e4e45439594fefcd2974e20554d1dc70b8e0 
34fd1787801343d5 f6edc95ce0348c25727c771526e3 fd4ef fb5f16e25alea3dcd82 
82e778e91ae9b339a5013c77 fd6ea2432704e293 £5e82a24121c73900bea4b4efl4a 
2adclab3c68224baelde9c61a48b84e84c1b0e83701be3d988012a24fa40268c8d6e 
f1fd2818ae8e4b6 f52f89beab6bfdd1f fib7ecd573edf f3703b800b5b2a206f451f1 
bf2713b4ae9085bd7 fe34ad4306a290e4cdb7817ee9ab/ccfb816d002b619F7 7d46d 
7TddOf8eefel0f5c0f9723 Ff fdb14ca75a185543770f41508b9983d5eed78225bc6e21 
f876bfdd08fe8bc63e0cb253c7dfc67c330897c515244 F3f631682F214leba48cas6 
dfff9206f78edcb9dec4b2371laeddbe141ef96a10957e29a94747c4438fb30b14d37 
e7428eb7 fbe4f9d870e72 F35 55847 F230374bd f56dcae6c129b4468ebaedc340fF4 
cc160c6b410e2d8989488ac8ef9a9I febbf65ad4fdfba532a8122ef82dcla4ffc361c 
bf9f752b36aa9821683d5f3f5842 f90134eb423d5cbc76858b4c0a7ba798ec94a089 
fdb24b5b25f42d7b6bb8192 fO7b98eb2delfe7bc8b6c740 fa5cde6fb4890d2Ff17916 
64a96c25a0a71a541025b5ec825eed91f393505473e21d0620177993982e6c1b6bf9 
1b777b5ab5739b84946c518c 7e6aa0e689e9ad1d34e6ef6ca0e709c4aefecd6f2594 
b017940742aceb72c5a52d7d47a3a74f9d09eb84c f82b349de32278a7 71cebc3l1lebc 
580c09b11799b1f0e6d11d75b17e389d259c531F957ale699250711df2e36f64F21c 
92ef f698a392d92d f0b2F91991408a076b83149e025a9f fbalfficaed916a2fclac5 
d3081c30b5c64b7d677c314b6e76ac20ed8bb4a4c0eb465ae5c0c265969264b27e6d 
54c266f79e58e2fa6a381069090bec00189562abc f831ladc86a05a2fc7f faa70dbd3 
fa60e09d447cd76b2f f£2b851c38e72650ade093ba8bd000000067b95de445abf8916 
ldff4b91a4a9e3bf156a39a4660f98f06bf3F017686d9dfc362c948646b3c9848803 
e6d9balf7d3967f709cddd35dc77d60356f0c36808900b491cb4ecbbabec128e7c81 
a46e62a67b57640a0a78belcbhf7dd9d419a10cd8686d16621a80816bfdb5bdc56211 
d72ca70b81f1117d129529a7570cf79cf52a7028a48538ecdd3b38d3d5d62d262465 
95c4fb73a525a5ed2c30524ebb1d8cc82e0c19bc4977c6898 FF95Ffd3d310b0bae716 
96cef93c6a552456b fF96e9d0 75e383bb7543c675842bafbfc7cdb88483b3276c29d4 
f0a341c2d406e40d4653b7e4d045851lacf6a0a0ea9c71Ob805cced4635ee8c107362 
f0fc8d80c14d0ac49c516703d26d14752f34c1c0d2c4247581c18c2c f4de48e9ce94 
9be7c888e9caebe4a415e291fd107d21dc1f084b1158208249f28f4Ff7c7e931ba7b3 
bd0d824a4570' 
] 
) 
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